Debugging

Various development and debugging assistance tools are provided in the ProtectToolkit-C SDK, including a full software emulation variant of the PKCS#11 library. One other such tool is the ProtectToolkit-C logger, a Cryptoki library replacement that intercepts all ProtectToolkit-C calls and reports them with their arguments to a log file before completing the call to the real Cryptoki library. The call results, return code, and arguments are likewise recorded to the same log file.

ProtectToolkit-C debugging techniques

• Use the ProtectToolkit-C token browser (CTBROWSE) to set up and inspect tokens and keys. The token browser can also be used to verify cryptographic operations, since just about any ProtectToolkit-C function can be called.

• Use the software-only emulation of PKCS#11 to avoid any hardware issues, including installation issues. This allows effective PKCS#11 development and debugging to be done on a laptop with no PCI bus for expansion cards, or when not connected to the same network as the HSM hardware.

• Use the ProtectToolkit-C logger to obtain PKCS#11 activity traces. This is useful for reporting problems to Thales support staff.

• Make all keys token keys (CKA_TOKEN = TRUE), rather than session keys. This can help to track down object leaks.

• Make all keys CKA_SENSITIVE=FALSE so they can be inspected with the token browser at any time.

• Use the Key Verification Codes (KVC) to check a key’s value without having to see the key’s value.

• Give every key a CKA_LABEL whether the application uses it or not. If there is an object leak where many key objects are being managed, the label may be the only way of tracking down the source code that created it.

ProtectToolkit-C debugging caveats

• Remember to switch off all debugging support code once the application is working, since some debugging techniques require disabling of normal security options. For example, CKA_SENSITIVE=FALSE. If this code remains active in a production system, security may be compromised.